“Business Rules and Data Requirements: Pulling in Tandem for Success” was the title of another session I attended at the WCBA conference. Mary Gorman, Senior Associate with EBG Consulting, focused on business rules and their relationship to data in the context of requirements elicitation.

Copyright Notice: Major portions of this blog post are from materials © EBG Consulting, Inc., 2009 Used with permission on ModernAnalyst.com

Before even diving into the mean of the presentation, Mary stressed the importance of realizing that no one requirements view or model is enough, by itself, do understand the requirements of a given system.

She covered again the four key requirements viewpoints:

• Behavior: e.g. process, action, function, task, script
• Structure: e.g. information, data, object
• Dynamics: e.g. time, lifecycles
• Control: e.g. business rules – the intersection of Behavior, Structure, and Dynamics

All these four views are very important and rely on each other to provide a holistic perspective of the requirements.

They key takeaways, for me, from the sessions were:

• Process/behavior requirements cannot stand by themselves but instead they trace to data and business rules (just process sis like sitting on a one legged stool)
• There is great risk when performing single-dimension requirements elicitation focusing on only one of the requirement viewpoints: business rules alone, business data alone, business process alone, etc.

That’s why you don’t see too many dedicated “Business Rule Analysts” or “Business Process Analyst”. The analyst must be a generalist or, as Scott Ambler likes to say a “specializing generalist” emphasizing that while you might want to specialize and be proficient in one or two disciplines (like business rules analysis, process analysis, etc.) you must also have a good understanding of all the other business analysis dimensions. Focusing on one area alone is like trying to sit on a one legged stool… you’ll be on the floor before you know it.

Identify Business Rules

When eliciting requirements, it is great if you are able to identify business rules as soon as you hear them even they might not be labeled as such by your stakeholders. To accomplish this, Mary suggests that the analysts watch for certain key words which serve as business rule giveaways.

Here are some of the business rules clues:

• classify,
• determine,
• compare,
• assess,
• evaluate,
• must,
• defined as,
• must not,
• calculated as,
• must only,
• If … then …
• etc.

Business Rule Classification

Term Rule: a business rules which defines a term of the business…. In every business domain it is critical to document all the rules defining the vocabulary to be used on the project.

Example 1: A Customer is defined as an individual or organization who purchased a product in our store.

Example 2: A Gift Card is defined as a product sold by our store that in turn can be used as a payment for other purchases.

As you can probably guess, your project glossary is a set of term business rules. 

By the way, for more details on business rules in the context of requirements elicitation process check out the The Software Requirements Memory Jogger. 

Fact Rule: Is a business rule which is part of the “fact model” (think logical data model) which outlines our understanding of truth related to previously identified terms.  

Article 3.2 of the Business Rules Manifesto states: “Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.”

Example 1: A Purchase is paid for by Gift Card, a Gift Card pays for a Purchase (shows the relationship between Purchase and Gift Card).

Example 2: A purchase may be paid by one or more Gift Cards, A Gift Card may pay for one or more Purchase (shows the cardinality between Purchase and Gift Card).

As you can see from the above two examples, fact rules are really facts which are generally documented and captured by logical data models of your system.

This example also reinforces the concept that while doing analysis of the business rules you will discover data requirements (business entities and their attributes) such as: customer, customer e-mail address, gift card, gift card balance (entity vs. attribute).

It is not possible to analyze business rules and not consider data requirements:

• Fact Rule: a customer has a name and address
• Data Attribute: customer first name, customer last name, customer semail address (attributes are atomic – cannot be broken down any further)

Constraint Rule:  is a business rule which places a constraint on data entities or data attributes.

Example: A Gift Card’s expiration date must be equal or greater than the Purchase’s purchase date.

Again, from the rule above you’ll see that we just discovered a data requirement to track and store yet another piece of data => Gift Card Attribute: expiration date (we need to remember the date in order to be able to enforce the constraint rule).

Derivation Rule: Is a business rule which explains how new data may be derived from other data. Think of these as calculations.

Example: Gift card expiration date is calculated as Gift Card activated date plus 365 days. 

And, of course, here is another new data requirement -we need to store yet another Gift Card Attribute: activation date.

Did you see how rules drive data – you discover data as you discover and document the rules.

Data Attribute Rule: Is a business rule which provides constraints on data attributes.

Example 1: Customer’s middle initial is an optional attribute when of purchasing a Gift Card.

Example 2: Gift Card Status has four allowable options: Purchased, Activated, Expired, and Depleted.

Mary suggested using a table as one option for capturing and documenting data attribute rules, such as:

Attribute Name	Definition	Required	Allowed Values	Data Type	Maximum Value	… <insert your own columns>
Customer first name	…	Yes – when creating a new customer	n/a	Alpha	n/a	…
Customer last name	…	Yes – when creating a new customer	n/a	Alpha	n/a	…
Customer middle initial	…	No	n/a	Alpha	n/a	…
Gift card purchase amount	…	No	n/a	Currency	n/a	…
Gift card status	…	Yes	Purchased, Activated, Expired, Depleted	n/a	n/a	…
Gift card original balance	…	Yes	n/a	Currency	$1,000.00	…

Of course, you can add additional columns to capture more detailed requirements about your data attributes such as: format/mask, minimum value, range of values, etc.

Separation of Concerns

Do your data definitions belong in your use case (or other behavioral artifact)?

Do your business rules belong in your use case (or other behavioral artifact)?

NO! They need to be in a separate/shared repository so that they can be reused.

One of the key concepts which were stressed in this session was the separation of concerns. While you may be doing it all during the requirements process: rules, data, process/behavior you also need to ensure that you have a way to manage the project’s processes, data, business rules, etc. as separate (yet interconnected) models rather than dumping your requirements into one catch-all document or format.

In her session, Mary Gorman covered many other topics related to business rules but this post would have been even longer.  Sorry - but I guess you'll have to hear her in person.

If you’re interested in my notes from Mary’s other WCBA session, visit: Jogging through the IIBA® BABOK® with the Requirements Roadmap

Useful Business Rules References 

 

Book: Business Rules Concepts by Ronald Ross

Article: Business Rules and Data Requirements by Mary Gorman

Article: Turning Rules into Requirements by Ellen Gottesdiener

Interview: What Analysts Need to Know about Decisioning and Business Rules - Interview with Ronald G. Ross

 

Business Rules Manifesto: The Principles of Rule Independence from the Business Rules Group

The Business Rules Manifesto*

Article 1. Primary Requirements, Not Secondary

1.1. Rules are a first-class citizen of the requirements world.

1.2. Rules are essential for, and a discrete part of, business models and technology models.

Article 2. Separate From Processes, Not Contained In Them

2.1. Rules are explicit constraints on behavior and/or provide support to behavior.

2.2. Rules are not process and not procedure. They should not be contained in either of these.

2.3. Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product

3.1. Rules build on facts, and facts build on concepts as expressed by terms.

3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.

3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.

3.4. Rules are basic to what the business knows about itself -- that is, to basic business knowledge.

3.5. Rules need to be nurtured, protected, and managed.

Article 4. Declarative, Not Procedural

4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.

4.2. If something cannot be expressed, then it is not a rule.

4.3. A set of statements is declarative only if the set has no implicit sequencing.

4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.

4.5. A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.

4.6. Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

4.7. Exceptions to rules are expressed by other rules.

Article 5. Well-Formed Expression, Not Ad Hoc

5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.

5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.

5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.

Article 6. Rule-Based Architecture, Not Indirect Implementation

6.1. A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.

6.2. Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

6.4. Rules are based on truth values. How a rule’s truth value is determined or maintained is hidden from users.

6.5. The relationship between events and rules is generally many-to-many.

Article 7. Rule-Guided Processes, Not Exception-Based Programming

7.1. Rules define the boundary between acceptable and unacceptable business activity.

7.2. Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.

7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.

Article 8. For the Sake of the Business, Not Technology

8.1. Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.

8.2. Rules always cost the business something.

8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.

8.4. ‘More rules’ is not better. Usually fewer ‘good rules’ is better.

8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

Article 9. Of, By, and For Business People, Not IT People

9.1. Rules should arise from knowledgeable business people.

9.2. Business people should have tools available to help them formulate, validate, and manage rules.

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

Article 10. Managing Business Logic, Not Hardware/Software Platforms

10.1. Business rules are a vital business asset.

10.2. In the long run, rules are more important to the business than hardware/software platforms.

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

10.4. Rules, and the ability to change them effectively, are fundamental to improving business adaptability.

*Version 2.0, November 1, 2003. Edited by Ronald G. Ross.

Copyright, 2006–2009. Business Rules Group.

Permission is granted for unlimited reproduction and distribution of this document under the following conditions: (a) The copyright and this permission notice are clearly included. (b) The work is clearly credited to the Business Rules Group. (c) No part of the document, including title, content, copyright, and permission notice, is altered, abridged, or extended in any manner.